Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Thanks @mariopaja for this fix. I confirm that it does fix the issue. This is due to the update done within the PR #94869 which ensure to perform the DMA_OFFSET shift in all DMA function entry-points, leading to getting a -1 channel id for dcmi for example on the H7.
While this does fix the issue, I am wondering why we need to keep such indexing different depending on platforms.
@erwango, Maybe I missed on part but wouldn't it be easier from a user point of view to always have channel id starting from 0 for all platforms, and not having to set them starting from 1 on some and from 0 for some others ?

@erwango, Maybe I missed on part but wouldn't it be easier from a user point of view to always have channel id starting from 0 for all platforms, and not having to set them starting from 1 on some and from 0 for some others ?

Problem is that on some series (say F0), channel index starts from 1 and channels are bound to a dedicated peripheral (Ie channel 1 bound to ADC for instance). So we need to respect this, otherwise it'll make configuration quite hard.

Coming back on the current issue, I need to have a deeper look.
I agree we should be able to use index starting from 0 on H7, as allowed by the IP. Though, no the other side, when dmamux is present, we're not supposed to reference dma1/2 directly but rather we should always go through dmamux, ie:

-			dmas = <&dma1 0 75 (STM32_DMA_PERIPH_TO_MEMORY | STM32_DMA_PERIPH_NO_INC |
+			dmas = <&dmamux1 0 75 (STM32_DMA_PERIPH_TO_MEMORY | STM32_DMA_PERIPH_NO_INC |

But then @mariopaja raises #93480 (comment) on which I don't have answer for now. I'll come back to you on this.

On the stm32H7 which has a DMAMUX, use the dmamux for the corresponding peripheral request : (channel is the one from 0..15)
for dcmi request is 75 :
dmas = <&dmamux1 0 75 (STM32_DMA_PERIPH_TO_MEMORY | STM32_DMA_PERIPH_NO_INC ...

for SAI 1 A request is 87 :
dmas = <&dmamux1 1 87 (STM32_DMA_PERIPH_TO_MEMORY | STM32_DMA_PERIPH_NO_INC ...

for SAI 1 B request is 88 :
dmas = <&dmamux1 2 88 (STM32_DMA_PERIPH_TO_MEMORY | STM32_DMA_PERIPH_NO_INC ...

And also enable DMAMUX1,DMA1,DMA2

&dma1 {
	status = "okay";
}
&dma2 {
	status = "okay";
};
&dmamux1 {
	status = "okay";
};

@FRASTM you are correct about the request but channel of DMAMUX seems to be hardwired #93480 (comment) .

And here starts my issue because it gives a limitation. For example SAI1 A & B nodes cannot be used simultaneously

@FRASTM you are correct about the request but channel of DMAMUX seems to be hardwired #93480 (comment) .

And here starts my issue because it gives a limitation. For example SAI1 A & B nodes cannot be used simultaneously

Did you try with SAI 1 A and SAI 2 B
SAI 2B request is 90 :
dmas = <&dmamux1 2 90 (STM32_DMA_PERIPH_TO_MEMORY | STM32_DMA_PERIPH_NO_INC ...

@FRASTM you are correct about the request but channel of DMAMUX seems to be hardwired #93480 (comment) .

And here starts my issue because it gives a limitation. For example SAI1 A & B nodes cannot be used simultaneously

Did you try with SAI 1 A and SAI 2 B

SAI 2B request is 90 :

dmas = <&dmamux1 2 90 (STM32_DMA_PERIPH_TO_MEMORY | STM32_DMA_PERIPH_NO_INC ...

I will not be able to test it before 06/10.

I think we have also drifted a bit from my issue. I tried to explain it once again at sai g4 PR